Export findings from the backend instead of loaded page state - #2453

Closes #1875

Problem

Findings export was assembled entirely in the browser:

const selectedFindings = findings.filter((f) => selectedIds.has(f.id))
exportFindingsAsCSV(selectedFindings)

findings is React state, so only findings already scrolled into memory could ever end up in the file. Select across pages and you got whatever happened to be loaded — silently, with no indication anything was missing.

Changes

POST /api/v1/findings/export resolves a selection of finding ids against the database and streams csv, json, or sarif back.

Three selection cases, deliberately distinct:

That last row matters: an empty selection must never be read as "everything". It is pinned by a test.

Memory

Findings are read in batches of SECUSCAN_EXPORT_BATCH_SIZE (500) and serialized as they go, so memory tracks the batch size rather than the size of the export. Both the read and the id-count are batched — an IN list is one bound parameter per id, and every database has a ceiling on those.

SARIF is the exception and is assembled in full. Its deduplicated rules array lives in the tool driver ahead of the results that index into it, so the whole set has to be known before the first byte is correct. SECUSCAN_MAX_EXPORT_FINDINGS (10000) is what bounds that; it rejects an oversized request rather than truncating it, so an export is never quietly partial.

Security

• Owner-scoped. Every query carries owner_id. Ids belonging to someone else are skipped rather than rejected, so the endpoint cannot be used to test whether a finding exists — and X-Export-Finding-Count does not confirm them either. Both are tested.
• Redacted. target, description, remediation, proof, confidence_reason, evidence, and metadata go through the same redaction.py helpers task reports use. One function gates every byte leaving the module, so CSV, JSON, and SARIF cannot drift apart.
• Rate limited on report_download_limiter, shared with report downloads.
• owner_id is dropped from the JSON export — constant for the whole file and useless inside it.
• Audit-logged as findings_exported with the format and the count.

Frontend

The Bulk Export control is now visible whenever there are findings, and its label states the scope: Export Selected (N) when something is checked, Export All (N) when nothing is. SARIF joins CSV and JSON in the dropdown. The button disables while an export is in flight, and a failure raises an error toast instead of downloading an empty file.

Removed

serializeFindingsToCSV, escapeCSV, exportFindingsAsCSV, and exportFindingsAsJSON are gone — the endpoint replaced their only caller. Their column contract did not go with them; it is now asserted in testing/backend/unit/test_finding_export.py, including the comma/quote/newline escaping the old frontend test covered. downloadFile is kept as a generic helper (now a one-liner over downloadBlob).

The CSV keeps the same 14 columns in the same order, so existing scripts keep working. One deviation: line endings are now RFC 4180 CRLF, matching the task-report CSV, where the browser emitted bare LF.

Verification

• testing/backend/integration/test_findings_export.py (new) — 28 tests
• testing/backend/unit/test_finding_export.py (new) — 22 tests
• Full backend integration — 344 passed, 9 skipped
• Full backend unit — 2343 passed, 21 skipped
• Full vitest run — 64 files, 566 tests passed
• ruff check backend testing/backend — clean
• tsc --noEmit — clean
• quality-gate.cjs — 13 passed, 0 failed (its 1 warning is a pre-existing 2000ms animation, unrelated)

Mutation-checked. Dropping owner scoping, treating [] as "everything", removing redaction, leaking owner_id, skipping the cap, un-batching the count, and removing the de-duplication each fail a test.

Two things I want to flag rather than bury:

1. test_duplicate_ids_do_not_duplicate_rows passes with or without the explicit de-duplication, because IN (?, ?, ?) already collapses repeats. It is kept as a contract guard against a future rewrite that resolves ids one query at a time, and says so.
2. The ORDER BY ..., id tiebreaker survives mutation under SQLite, which happens to page tied rows consistently. It is there for PostgreSQL, which is under no such obligation. Also noted in the code.

Overlap with #2394 — please read before merging either

@namann5's #2394 neutralizes CSV formula injection (CWE-1236) in escapeCSV and in ReportGenerator._sanitize_csv_cell. This PR deletes escapeCSV and moves findings-CSV generation to the backend, so merging the two naively would have quietly reopened that hole for the findings export.

I checked rather than assumed, and the new writer was vulnerable:

f-1,"=HYPERLINK(""http://evil.example"",""click"")",,,+cmd|'/C calc'!A0,…

So finding_export.sanitize_csv_cell is now applied to every cell, deliberately mirroring #2394's semantics (=, +, -, @ → single-quote prefix) so the report CSV and the findings CSV cannot disagree about what is safe to hand a spreadsheet. Covered by unit tests and an end-to-end test that seeds a hostile finding title and asserts what lands in the file, and mutation-checked three ways (guard disabled, narrowed to = only, not wired into the row builder).

Once both land, the two helpers should be folded into one. I left them separate only because #2394 is unmerged and this PR has to be safe standing alone. Happy to do that consolidation as a follow-up, or to rebase onto #2394 and use their helper directly if you would rather merge that one first.

Note on merge order

Conflicts, both verified with git merge-tree:

Happy to rebase onto whichever you take first — just say which.